Skip to content
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.

OKRs - 2019 Q1 JS Core WG #799

Merged
merged 6 commits into from
Feb 5, 2019
Merged

OKRs - 2019 Q1 JS Core WG #799

Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
d3c5bea
docs: 2019 Q1 JS IPFS WG OKRs
Dec 11, 2018
e8837ae
feat: WIP intitial stab at OKRs and prioritising
Dec 18, 2018
7dbda1d
docs: updated OKRs
Dec 19, 2018
7bdd947
Update JS_CORE.md
Dec 19, 2018
6ce59fd
refactor: drop homebrew for more complete API
Dec 19, 2018
181fa6a
feat: add connectivity KR
Dec 19, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions OKR/JS_CORE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,27 @@

We frame our ongoing work using a process based on quarterly Objectives and Key Results (OKRs). Objectives reflect outcomes that are challenging, but realistic. Results are tangible and measurable.

## 2019 Q1

### A complete implementation of IPFS in JavaScript

* p0 - Base32 encoded version 1 CIDs are the default for new content added to IPFS [@alanshaw](https://github.com/alanshaw)
* p0 - IPNS has a streaming API [@vasco-santos](https://github.com/vasco-santos)
Copy link
Member

@lidel lidel Dec 23, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 as this will enable ipfs/ipfs-companion#643 with js-ipfs :)

* p1 - IPNS supports `ttl`, `dhtt` and `dhtrc` parameters and republish configurations [@vasco-santos](https://github.com/vasco-santos)
* p1 - A repo migration tool exists and JS IPFS can automatically upgrade older repos [@achingbrain](https://github.com/achingbrain)
* p2 - Vital missing APIs are implemented i.e. `/dag/put`, `/dag/resolve`, `/repo/gc`, `/refs` and `/swarm/filters/*` [@achingbrain](https://github.com/achingbrain)

### Used in production

* p0 - A JS IPFS daemon is one (or more!) of the IPFS gateway nodes [@alanshaw](https://github.com/alanshaw)
* p2 - Perf benchmarking site is launched and 10 different benchmarking scenarios exist [@alanshaw](https://github.com/alanshaw)
* p0 - IPFS is a transport for [npm/tink](https://github.com/npm/tink) [@achingbrain](https://github.com/achingbrain)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: This objective should contain a KR on "js-ipfs can find (Peer Routing) any peer and dial to it (direct or relay) if this Peer is online."

Potentially adding a job that keeps trying to dial to many different nodes in the network, just to be sure that the connection always happens.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Potentially adding a job that keeps trying to dial to many different nodes in the network, just to be sure that the connection always happens.

This is to mitigate against a failed connection due to network error or your laptop goes offline or something? I'm surprised this isn't already implemented!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alanshaw I meant a job in our infra that keeps checking that JS can make quality connections everywhere as the network grows. But yeah, your proposal (if not done yet) is sound too.

### Inviting for developers and contributors

* p1 - Continuous deployment drives `js-ipfs-unixfs-*` and `js-ipfs-mfs` [@achingbrain](https://github.com/achingbrain)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What work does this KR translate into?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once we settle on a new CI this'll involve:

  1. Figuring out a strategy to use e.g. solving questions like:
    • does publish a prerelease or a release?
    • how does CI know what version number to increment?
    • when does a release happen? push to master?
  2. Configuring the CI to enact the release ensuring secrets are handled correctly
  3. Testing the setup beforehand on a test module

* p1 - Core APIs are refactored to use async await/iterators; at least half the repos in scope have a proposal/PR [@alanshaw](https://github.com/alanshaw)

## 2018 Q4

- [js-ipfs 2018 Q4 OKRs](https://docs.google.com/spreadsheets/d/139lROP7-Ee4M4S7A_IO4iIgSgugYm7dct620LYnalII/edit#gid=274358435)
Expand Down