2018 Q4 OKRs Planning #1566

daviddias · 2018-09-15T18:31:03Z

2018 Q3 Retrospective Document. Please complete this ASAP.
Previous OKR Planning for reference
2018 Q4 OKR Spreadsheet

@alanshaw, @hugomrdias, @achingbrain et al, you know the drill :)

daviddias · 2018-09-21T15:05:01Z

Here goes my first suggestions:

js-ipfs needs to be capable of handling transferring a dataset such as ImageNet (large shareded directory) and not more far than one order of magnitude from go-ipfs performance
npm-on-ipfs becomes the default registry that we as IPFS devs use to install npm dependencies
Performance and Stability harness is built. We get tests with 50000 nodes.

daviddias · 2018-09-22T17:55:06Z

I've captured notes from the Retrospective and delivered them as feedback and proposed OKRs for the DX team -- ipfs-inactive/dev-team-enablement#142.

daviddias · 2018-09-22T18:02:57Z

I've also captured the notes from the Weekly Discussions and Retrospectives and communicated to the @ipfs/infrastructure Team our proposed OKRs at ipfs/infra#434

daviddias · 2018-09-22T18:27:53Z

More proposals:

The Awesome DHT Endeavour is landed - Awesome Endeavour: DHT Part II #856, there fore completing the last milestone of Connectivity Magic
Base32 CID Migration is complete
Onboard 3 new contributors

daviddias · 2018-09-22T18:39:33Z

Another one:

Something around Perf Profilling. Previous work is https://github.com/ipfs/ipfs-performance-profiling and https://github.com/ipfs/benchmark.js.ipfs.io/

achingbrain · 2018-09-24T11:20:06Z

I want to:

Get everyone on npm-on-ipfs. This will involve at least:
1. Shoring up the hosting situation
2. Having CI use it
3. ipnpm install or similar
Decompose js-ipfs-unixfs-engine into smaller modules
Bottom out unixfs-v2
Decompose js-ipfs into smaller modules similar to the approach taken with js-ipfs-mfs

I'd also like to see opt-in continuous deployment for JS projects. E.g. you merge a PR, Jenkins builds it, revs the version number and publishes a new version to npm or deploys an app, etc.

hugomrdias · 2018-09-24T12:06:05Z

The main topics/areas i think we should improve are:

error handling, build upon the work Alan/Jacob already did with err-code plus i think we can define static error codes in a file and export them for use just like node does.
cli level up, continue the work in this PR feat: improved error handling on the CLI #1335, simplify the flow, add more features in line with go impl
add logging and error tracking (ex. https://sentry.io) for long running js nodes
improve tests, remove duplication (ipfs-api, ipfs, ctl, interface all test the same code multiple times), cli tests can use yargs.parse instead of actually spawning processes
make ipfs and ipfs-api smaller and easier to bundle and uglify
optimise hot code paths (get/cat/add) in line with my big data work and David suggestions above Perf Profilling and js-ipfs needs to be capable of handling transferring a dataset such as ImageNet (large shareded directory) and not more far than one order of magnitude from go-ipfs performance, i have a lot of half done work on this i would like to finish. This should focus on simplifying code, benchmark alternative implementations of key components, profile/debug bottlenecks on mem and cpu (but mostly mem for now, better to be slow than crash)
improve service worker DX and features ref. https://github.com/ipfs/developer-meetings/blob/master/sessions/deep-dive/service-worker.md
make more issues like this A viable alternative to go-ipfs? #1563 and to get feedback from what ppl really need from the js impl. Implement this A viable alternative to go-ipfs? #1563 (comment) would be cool :)

alanshaw · 2018-09-24T15:31:52Z

npm-on-ipfs becomes the default registry that we as IPFS devs use to install npm dependencies

ha, done. I've been using it for weeks now!

Seriously though, +1 on this, and using it on CI.

alanshaw · 2018-09-24T15:34:44Z

Personally I need to focus on completing the work I started last quarter:

Complete CIDv1 base32 work
Setup and run a js-ipfs daemon on the wider internet & address any further crashes

It's super important that CIDv1 base32 becomes a thing from a security perspective for the gateways, but also...TODO

In the retrospective for Q3 I listed this:

Get metrics for slow test improvements

I've made progress on speeding up JS IPFS in Q3 (ipld/js-ipld#145, #1528, #1542, ipfs-inactive/dev-team-enablement#73), but there's not just one thing that contributes to slowness. I think rather than gathering stats on this particular round of improvements, time would be better spent identifying some useful benchmarks and creating a re-usable harness that can be run against js-ipfs to track and graph performance over time.

We should also be able to run these for older releases and compare and contrast with the same benchmarks in go-ipfs. Maybe iptb is the thing to use for this?

The biggest thing I see as a hurdle to js-ipfs being a viable alternative to go-ipfs is not having a DHT. This is the last step of our connectivity magic plan, and I think that it'll enable people to seriously use js-ipfs (outside of a browser context) as a serious alternative to go-ipfs.

daviddias · 2018-09-25T09:27:18Z

@alanshaw, @hugomrdias and @achingbrain, wanna take a stab of converting the KRs proposed in this doc into a commit to the OKR file so that we can then evaluate together? Following of how we've done this in the past and how js-libp2p continued the tradition.

alanshaw · 2018-09-25T22:28:21Z

@diasdavid @hugomrdias @achingbrain I've added a first pass attempt, please let me know what you think 😄

daviddias · 2018-09-26T03:38:45Z

OKR.md

+* P0 - @hugomrdias - JS IPFS is capable of transferring a large dataset like ImageNet at least 75% as fast as Go IPFS
+* P2 - @hugomrdias - The browser bundle of IPFS is not more than 1.5MB (gzipped) in size
+* P3 - @hugomrdias - Browser bundle size is measured over time and developers alerted if it increases above 1.5MB
+* P1 - @alanshaw - A website is published to visually track a set of basic performance profiles of JS IPFS releases over historical versions


Could it be continuing the work of https://github.com/ipfs/benchmark.js.ipfs.io?

I will certainly be looking at how it can be used/extended!

daviddias · 2018-09-26T03:40:13Z

OKR.md

+
+* P0 - @hugomrdias - Error codes are added to all errors that originate directly from JS IPFS
+* P2 - @alanshaw - Test quality is improved, duplicates removed and coverage increased
+* P0 - @achingbrain - js-ipfs-unixfs-engine is decomposed into smaller modules for better maintainability, testability and reliability. The refactored modules are part of a JS IPFS release


Make sure to extract the HAMT so that it can be used as a generic KV store on top of IPLD //cc @mikeal

daviddias · 2018-09-26T03:40:29Z

OKR.md

+# Stable and future proof
+
+* P0 - @hugomrdias - Error codes are added to all errors that originate directly from JS IPFS
+* P2 - @alanshaw - Test quality is improved, duplicates removed and coverage increased


Over the entire project? Better take a snapshot then :)

daviddias

👏🏽👏🏽👏🏽

I like these!

eefahy · 2018-09-26T03:46:01Z

OKR.md

+* P2 - @alanshaw - Test quality is improved, duplicates removed and coverage increased
+* P0 - @achingbrain - js-ipfs-unixfs-engine is decomposed into smaller modules for better maintainability, testability and reliability. The refactored modules are part of a JS IPFS release
+* P2 - @achingbrain - Candidate modules for extraction from JS IPFS (e.g. js-ipfs-mfs) are identified and agreed
+* P1 - @achingbrain - Continuous deployment is an option for all Protocol Labs JS projects. 3 IPFS/IPLD/libp2p projects are setup to be continuously deployed


an helpful deliverable on this would be deploy requirement docs for each project to help during CD implementation.

eefahy · 2018-09-26T03:50:39Z

OKR.md

+* P0 - @vasco-santos - DHT is enabled by default and interoperates with Go IPFS DHT
+* P1 - @vasco-santos - IPNS is functional over pubsub and the DHT
+* P0 - @alanshaw - Base32 CIDv1 migration is complete
+* P0 - @alanshaw - A JS IPFS daemon is part of the IPFS gateways


what does "is part of" mean here?

I mean that it is one (or more!) of the nodes that belong to the IPFS gateway.

Obvisously this will require close communication with the infra team and I anticipate working on requirements the infra team may have for an IPFS gateway node (setup?, reporting?, throughput?, stability?). I'm thinking we'll likely want to "soft" launch and gradually ramp up traffic being directed to the node as performance and stability are proven.

vasco-santos · 2018-09-26T09:03:07Z

@alanshaw it would be nice to have a repo migration tool. What do you think?

alanshaw · 2018-09-26T09:57:11Z

@vasco-santos thanks for raising this - yes we really need that, we spoke offline and it looks like your time constraints won't allow you to get to it this quarter. I think we might have to bump it to next quarter unless @achingbrain or @hugomrdias feel they can also fit this in!?

achingbrain · 2018-09-26T10:08:24Z

I could take that on, would love to get a bit deeper into the repo

achingbrain · 2018-09-26T10:10:18Z

Maybe drop the unixfs-v2 thing from my OKRs - there's this already: ipld/legacy-unixfs-v2#12 and @mikeal seems to be pushing ahead with that.

alanshaw · 2018-09-26T10:34:25Z

@achingbrain it would be beneficial for the unixfsv2 spec to have been reviewed, and possibly had input from someone who has intimate knowledge of v1. You built the JS MFS implementation and are the lead maintainer for js-ipfs-unixfs-engine. I can't think of someone more qualified to do that from the JS team 😄

It sounds like @mikeal has the same goal to have a draft ready by the end of Q4 - it would be awesome if you could help him pull it over the line?

alanshaw · 2018-09-26T10:59:42Z

@diasdavid @achingbrain @hugomrdias @vasco-santos I'm going to transfer these to the spreadsheet now as it looks like we're nearly done 😱. Please double check the latest changes here 🚀 🚢 👍 😃

daviddias · 2018-09-28T16:28:21Z

OKR.md

-* P2 - @achingbrain - Candidate modules for extraction from JS IPFS (e.g. js-ipfs-mfs) are identified and agreed
-* P1 - @achingbrain - Continuous deployment requirements for infra are established making CD an option for all PL JS projects. 3 IPFS/IPLD/libp2p projects are setup to be continuously deployed
-* P2 - @achingbrain - A draft spec for unixfs-v2 is finalized
+Find the **js-ipfs OKRs** for 2018 Q4 at the [2018 Q4 IPFS OKRs Spreadsheet](https://docs.google.com/spreadsheets/d/139lROP7-Ee4M4S7A_IO4iIgSgugYm7dct620LYnalII/edit#gid=274358435)


⚡️👏🏽👍🏽

daviddias assigned alanshaw, hugomrdias and achingbrain Sep 15, 2018

ghost assigned daviddias Sep 15, 2018

ghost added the status/in-progress In progress label Sep 15, 2018

daviddias mentioned this pull request Sep 15, 2018

2018 Q4 OKR Planning - It's that time of the quarter again ✨ ipfs/team-mgmt#698

Closed

docs: 2018 Q4 OKRs

8a09293

daviddias force-pushed the 2018-Q4-OKRs branch from 29a9bee to 8a09293 Compare September 22, 2018 18:21

docs: first pass Q4 OKRs

27be7dd

daviddias commented Sep 26, 2018

View reviewed changes

eefahy reviewed Sep 26, 2018

View reviewed changes

Update OKR.md

159af4a

docs: add link to Q4 2018 OKRs

c77e529

alanshaw approved these changes Sep 28, 2018

View reviewed changes

alanshaw merged commit 2d7cfc5 into master Sep 28, 2018

ghost removed the status/in-progress In progress label Sep 28, 2018

alanshaw deleted the 2018-Q4-OKRs branch September 28, 2018 14:31

daviddias commented Sep 28, 2018

View reviewed changes

daviddias mentioned this pull request Dec 8, 2018

It's that time of the Quarter again ✨ - 2019 Q1 Planning 🎉 ipfs/team-mgmt#792

Closed

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

2018 Q4 OKRs Planning #1566

2018 Q4 OKRs Planning #1566

daviddias commented Sep 15, 2018 •

edited

Loading

daviddias commented Sep 21, 2018 •

edited

Loading

daviddias commented Sep 22, 2018

daviddias commented Sep 22, 2018

daviddias commented Sep 22, 2018 •

edited

Loading

daviddias commented Sep 22, 2018

achingbrain commented Sep 24, 2018

hugomrdias commented Sep 24, 2018

alanshaw commented Sep 24, 2018

alanshaw commented Sep 24, 2018 •

edited

Loading

daviddias commented Sep 25, 2018

alanshaw commented Sep 25, 2018

daviddias Sep 26, 2018

alanshaw Sep 26, 2018

daviddias Sep 26, 2018

daviddias Sep 26, 2018

daviddias Sep 26, 2018

daviddias left a comment

eefahy Sep 26, 2018

eefahy Sep 26, 2018

alanshaw Sep 26, 2018

vasco-santos commented Sep 26, 2018

alanshaw commented Sep 26, 2018

achingbrain commented Sep 26, 2018

achingbrain commented Sep 26, 2018

alanshaw commented Sep 26, 2018

alanshaw commented Sep 26, 2018

daviddias Sep 28, 2018

2018 Q4 OKRs Planning #1566

2018 Q4 OKRs Planning #1566

Conversation

daviddias commented Sep 15, 2018 • edited Loading

daviddias commented Sep 21, 2018 • edited Loading

daviddias commented Sep 22, 2018

daviddias commented Sep 22, 2018

daviddias commented Sep 22, 2018 • edited Loading

daviddias commented Sep 22, 2018

achingbrain commented Sep 24, 2018

hugomrdias commented Sep 24, 2018

alanshaw commented Sep 24, 2018

alanshaw commented Sep 24, 2018 • edited Loading

daviddias commented Sep 25, 2018

alanshaw commented Sep 25, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daviddias left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vasco-santos commented Sep 26, 2018

alanshaw commented Sep 26, 2018

achingbrain commented Sep 26, 2018

achingbrain commented Sep 26, 2018

alanshaw commented Sep 26, 2018

alanshaw commented Sep 26, 2018

Choose a reason for hiding this comment

daviddias commented Sep 15, 2018 •

edited

Loading

daviddias commented Sep 21, 2018 •

edited

Loading

daviddias commented Sep 22, 2018 •

edited

Loading

alanshaw commented Sep 24, 2018 •

edited

Loading